IBIS Macromodel Task Group Meeting date: 01 March 2022 Members (asterisk for those attending): Achronix Semiconductor: Hansel Dsilva Amazon: John Yan ANSYS: * Curtis Clark * Wei-hsing Huang Cadence Design Systems: * Ambrish Varma Jared James Google: Zhiping Yang Intel: * Michael Mirmak Kinger Cai Alaeddin Aydiner Keysight Technologies: * Fangyi Rao Majid Ahadi Dolatsara * Ming Yan Radek Biernacki Rui Yang Luminous Computing David Banas Marvell Steve Parker Mathworks (SiSoft): * Walter Katz Mike LaBonte Micron Technology: Randy Wolff * Justin Butterfield Missouri S&T Chulsoon Hwang Siemens EDA (Mentor): * Arpad Muranyi Teraspeed Labs: * Bob Ross Zuken USA: * Lance Wang The meeting was led by Arpad Muranyi. Curtis Clark took the minutes. -------------------------------------------------------------------------------- Opens: - None. ------------- Review of ARs: - Arpad to send out BIRD213.1 draft 14 incorporating the meeting's changes. - Done -------------------------- Call for patent disclosure: - None. ------------------------- Review of Meeting Minutes: Arpad asked for any comments or corrections to the minutes of the February 22nd meeting. Michael moved to approve the minutes. Curtis seconded the motion. There were no objections. ------------- New Discussion: BIRD213.1 draft 14, PAMn: Arpad shared draft 14. Michael reported that he had been receiving inquiries from many people who were eager to see this functionality added to the specification. Michael asked for confirmation that the BIRD left the mapping of symbols to PAMn levels up to the tools. Arpad agreed. Fangyi said the original draft contained mapping information, but that Ambrish had rightly pointed out that mapping should be the job of the EDA tool. For example, IBIS doesn't get involved with 8b10b encoding. Michael said IBIS is sticking at the PHY layer and not getting involved with encoding. Fangyi and Ambrish agreed. Arpad noted that IBIS hadn't been entirely consistent on this point, and legacy PAM4 parameters included PAM4_Mapping, which mentions Gray code. Fangyi noted an inconsistency, in the Usage Rules for PAM_Thresholds, in the language used to describe the location of the "eyes". The second paragraph of the section described the progression of eyes: "The eye with the lowest threshold voltage is eye "1", the eye with the next threshold voltage up is eye "2", ..." In the bulleted list that follows, however, the definitions of the voltage ranges corresponding to symbol values referred to rows in the PAM_Thresholds Table. That is, eye 1 corresponds to the value in row 1 of the PAM_Thresholds parameter, eye 2 corresponds to row 2, etc. Fangyi said it was inconsistent to talk about the lowest threshold voltage in one instance and the first row (first value) in the table in another instance. Fangyi said the second paragraph implied tools should sort the thresholds. Walter said that as you proceed up in rows the thresholds should be increasing. Fangyi asked if we should enforce that monotonicity in values returned by the model. Arpad asked if there would be any expectation that they could be out of order. Fangyi said that as a practical matter, if they're out of order, then the design has probably failed. He said model makers were probably the best people to decide if this language was an issue. If we were to keep the language as written, then we could not model any swizzling of the thresholds. Justin said he didn't have a strong opinion at this point and wasn't sure if it would ever become an important distinction. Arpad asked if the language was sufficient for us to vote to move it to the Open Forum. Curtis said he thought we should clean up the inconsistency Fangyi had pointed out. Fangyi took an AR to propose new language based solely on row entry not threshold voltage value. Walter recalled that Ambrish had suggested that instead of Tables we use String Type parameters whose values are space delimited lists of numbers for PAM_Offsets and PAM_Thresholds. Walter had added an example of such an approach in the BIRD as a place holder. Ambrish agreed that this was his suggestion. Ambrish moved to use String Type parameters instead of Tables for PAM_Offsets and PAM_Thresholds. Arpad said he was somewhat sympathetic to this suggestion and that tables could be more complex to understand and parse in the .ami file. Curtis said he was interested in the group discussing it further. Curtis seconded Ambrish's motion. Bob said he preferred the Table, and he saw no reason to introduce any extra complexity in the text to define the contents of the String. With the current approach, it's just a Table of Floats and everything is understood. Walter said he thought the Table was the AMI way to do it, but he had no major objection to the String suggestion. He said he would abstain from any vote and leave it to the rest of the group. Arpad asked model makers which one they thought would be easier and whether we should consider allowing both. Curtis said he would probably not vote for allowing both methods. We should pick one and stick with it. The group discussed issues with how a single String value would be parsed and how hard it would be to define the numerical format of the String value. Some attendees suggested that it would take too much effort to capture the definition of the single String value in the specification. Michael said that on one hand he agreed that Tables aren't seen that often in the wild. However, he said feedback he was receiving indicated that people wanted this functionality as soon as possible. He wasn't sure it was worth delaying its progress to discuss use of String Type parameters. Ambrish withdrew his motion with the understanding that he might make it again at a later date. AMI Parameter tree root name clarifications BIRD draft: Michael reported that he had received no new feedback since publishing draft 3, aside from Arpad's comments, which had been set to the ATM list in reply. - Michael: Motion to adjourn. - Curtis: Second. - Arpad: Thank you all for joining. AR: Fangyi to propose language changes for PAM_Thresholds Usage Rules in BIRD213.1. ------------- Next meeting: 08 March 2022 12:00pm PT ------------- IBIS Interconnect SPICE Wish List: 1) Simulator directives